Field service applications may be any application in which companies dispatch technicians and/or other staff to remote locations in order to perform certain activities, for example, installations, services and/or repairs. Field service applications may exist in industries, such as, but not limited to, network installations, utility installations, security systems, construction, medical equipment, heating, ventilating and air conditioning (HVAC) and the like.
I. Locate Operations
An example of a field service application in the construction industry is a so-called “locate operation” (sometimes also referred to as a “locate and marking operation”), in which a locate technician visits a work site to determine a presence or an absence of one or more underground facilities (such as various types of utility cables and pipes) in a dig area to be excavated or disturbed, and marks the presence or the absence of facilities in and/or in proximity to the dig area. In some states and municipalities, an excavator is required by law to notify any potentially affected underground facility owners prior to undertaking an excavation activity. This notice may be served by contacting a “one-call center,” which may be a non-profit service operated by a consortium of underground facility owners, and by providing to the one-call center a description of the planned dig area.
FIG. 1 illustrates an example in which a locate operation is initiated as a result of an excavator 110 providing an excavation notice to a one-call center 120 (e.g., via an electronic mail message, a web entry, or a telephone conversation between the excavator 110 and a human operator at the one-call center 120). The excavation notice may include an address at which the excavation is to be performed and a description of the dig area, such as its location relative to certain landmarks and/or its approximate dimensions. Based on this information, and any additional information the one-call center 120 may have access to (e.g., existing maps of underground facilities and/or “polygon maps” that show buffer zones around underground facilities), the one-call center 120 creates a locate request ticket (also known as a “locate ticket,” or simply a “ticket”) and sends the ticket to one or more locate service providers 130. The one-call center 120 may additionally send the ticket to one or more underground facility owners 140, so that the underground facility owners 140 may perform audits on the locate service providers 130.
Alternatively, an underground facility owner 140 may operate its own fleet of locate technicians (e.g., locate technician 145), in which case the one-call center 120 may send the ticket to the underground facility owner 140 but not the locate service providers 130.
Upon receiving the locate request ticket, a locate service provider 130 may dispatch a locate technician 150 to the dig area to determine and/or mark a presence or absence of one or more underground facilities. This activity typically is referred to as a locate and marking operation (or simply a “locate”) during which the technician locates and marks any underground facilities that are found in the dig area. The locate technician 150 may use an underground facility locate device for detecting the presence or absence of facilities that are concealed in some manner, such as cables and pipes that are buried underground. For example, the underground facility locate device may detect changes in an electromagnetic fields that may indicate the presence of an underground facility. Once an underground facility is detected, the locate technician may mark the presence of the facility by some type of marker; for example, the technician may use a marking device to dispense a marking material (e.g., paint, chalk or dye) on the surface of the ground to indicate the location of the detected underground facility. In some cases, the technician also may provide one or more marks to indicate that no facility was found in the dig area (sometimes referred to as a “clear”).
The locate service provider 130 may handle a high volume of locate request tickets on a daily basis. For example, the locate service provider 130 may have locate offices (or profit centers) in different geographical regions and each locate office may have a hundred or more locate technicians in the field each day. Depending on its size, each locate office may respond to hundreds or even thousands of locate request tickets on a given day.
Conventionally, incoming locate request tickets are dispatched (or various information derived from such tickets is dispatched) to individual locate technicians based on geography. For example, the geographical region (e.g., a county) for which a locate office is responsible may be further divided into smaller geographical areas (e.g., cities or neighborhoods), and each geographical area may be assigned to a locate technician. Incoming locate request tickets are then assigned/allocated to different locate technicians based on the geographical areas in which the dig areas fall.
Throughout a work day, each locate technician maintains a list of outstanding activities to be performed on that day, based on the tickets assigned to the technician. The locate technician is responsible for scheduling and/or routing the outstanding activities. This is done conventionally in an ad hoc manner by the locate technician, for example, by manual inspection of the relative locations of the outstanding activities.
II. 360 Dynamic Scheduling Engine
More sophisticated scheduling and routing techniques have been employed in some other field service applications, such as appliance repair, utility installation and meter reading. For example, software applications have been adopted in these applications to facilitate the scheduling of field service activities performed by mobile technicians. One such application is the 360 Dynamic Scheduling Engine (also referred to simply as “360 DSE”). 360 DSE is a software application platform available from 360 Scheduling, Strelley Hall, Main Street, Strelley, Nottingham, NG8 6PE, United Kingdom (more information available at http://www.360scheduling.com). Several features of 360 DSE are summarized below, while further details can be found in “360 Concepts Guide 4.9.6, User Guide,” which is incorporated herein by reference. For purposes of the present disclosure, an “engine” (e.g., a “scheduling engine”) refers generally to a computing device (e.g., which may include one or more processors, memory, user interface, display, communications interface, signal and/or data input/output interface(s), etc.) executing one or more applications (e.g., software, computer-executable code, etc.) to perform some particular functionality as encoded in the application(s).
At a high level, 360 DSE receives as input a set of information relating to activities to be performed and resources available (e.g., technicians) for performing those activities. The output of 360 DSE is a schedule (or a plan) that indicates what is to be done, when, by whom and in some instances with what equipment. For example, the input information may include various constraints associated with the activities, such as location, timing and/or technician skill level requirements. The input information may also include constraints associated with the resources, such as available shift times and/or skill levels. Additionally, the input information may include revenue generated by the activities and costs associated with performing the activities, such as travel and/or overtime costs. Given the input information, 360 DSE attempts to search for a plan that satisfies all of the constraints and maximizes overall value (e.g., overall profit given by total revenue less total cost). In other words, 360 DSE attempts to solve an optimization problem against the value metric, where the optimization problem is parameterized by the input constraints.
In many cases, the output of 360 DSE may not be a strictly optimal plan, because the amount of computation required to search for a strictly optimal plan may be prohibitively large. Instead, 360 DSE aims to produce a “good” plan relatively quickly. For example, the plan returned by 360 DSE may be a best plan that 360 DSE is able to construct with respect to the value metric within a given amount of time. Along with the plan, 360 DSE may return a plan quality score on a scale from 0 to 100. This quality score may be calculated mathematically based on the search leading to the plan and may reflect a relative confidence level that the plan is indeed a best plan. Hereafter, the terms “optimized schedule” or “optimized plan” are used to refer broadly to any result produced by a software application for scheduling activities, such as 360 DSE.
FIG. 2 illustrates an example of a conventional application of 360 DSE. In this example, a number of activities 210A, 210B, . . . , are to be scheduled by 360 DSE (shown in FIG. 2 as component 220). Various information regarding each activity is provided to 360 DSE, such as an expected duration, a location, an availability period and a service level agreement (hereafter “SLA”) definition. For example, as shown in FIG. 2, the activity 210A may be a utility installation activity that has an expected duration of two hours and is to be performed at the location indicated by the latitude-longitude pair <51.5, −1.45>. The availability period indicates a window of time during which the activity 210A may be performed, for example, a four-hour window from 09:00 hours to 13:00 hours on Apr. 20, 2009. This window may be the result of an appointment made with the customer to gain access to a building in which the utility installation is to be performed.
The SLA definition is a set of parameters for modeling business rules associated with an activity to enable a determination of the importance of the activity relative to other activities at a given point in time. As discussed above, 360 DSE uses the value metric (e.g., revenue less cost) to evaluate and compare different candidate plans. The parameters in an SLA definition for an activity determine a time-varying curve (hereafter an “SLA curve”), where each point on the curve indicates the revenue that would be generated by completing the activity at that point in time. Additionally, an aging factor may be applied to scale up an SLA curve on a daily basis, to encourage 360 DSE to prioritize older activity over newer activities. Different types of SLA curves and their uses are discussed further below in connection with various embodiments.
360 DSE stores the received activity information in a database 230. Additionally, the database 230 may store information regarding a set of resources corresponding to mobile technicians and a set of parts corresponding to tools, materials and/or equipment used by the mobile technicians to perform various activities. For example, the database 230 may store, for each resource, shift times during which the resource is available. A skill level may also be stored for each resource and taken into account when scheduling activities requiring different skill levels. Furthermore, the database 230 may store information that enables 360 DSE to calculate travel cost, overtime cost, and/or any other costs that may be incurred while performing an activity.
Based on any newly received information and the information previously loaded to the database 230, 360 DSE produces a plan that allocates to each available resource a list of activities to be performed over a pre-determined scheduling window (e.g., two or more days beginning from the current time). This process (i.e., loading up-to-date information to the database 230 and running 360 DSE to produce a new plan) may be repeated periodically, for example, once a day, so that each run of 360 DSE takes into account new information that has become available since the previous run.
As shown in FIG. 2, a plan produced by 360 DSE may be reviewed and acted upon by a human dispatcher 240 via an auxiliary software application 250. This application, called the 360 Scheduling Work Bench (hereafter the “360 SWB”), provides a graphical user interface through which the human dispatcher may interact with 360 DSE.
FIG. 3 shows an example of a plan for five resources, 1000 through 1004, presented by the 360 SWB in a Gantt chart format. For each allocated activity (e.g., activity 28 as indicated by a bar 310 in FIG. 3), the plan specifies a scheduled start time and a scheduled end time (e.g., from 9:30 hours to 10:30 hours on Jan. 1, 2006). Each allocated activity may also be preceded and/or followed by a period of travel time (e.g., from 9:00 hours to 9:30 hours for activity 28, as indicated by a thin bar 320 in FIG. 3).
Returning to FIG. 2, the human dispatcher 240 may use 360 SWB to select an activity and commit it to a resource, which may or may not be the resource to which 360 DSE has allocated the activity. Once an activity is committed to a resource, 360 DSE will not attempt to re-allocate the activity to a different resource during a subsequent run. The dispatcher 240 may then finalize a plan for a resource by forwarding to the resource the list of activities committed thereto and instructing the resource to perform the activities at the scheduled times. For example, FIG. 2 shows resources 1000 through 1002 each receiving a corresponding finalized plan.